Amethodology

A pattern is a solution to a problem in a context. This paper uses the pattern form to address a basic problem in software development today: which methodology shall we pick to rule our project? Introduction You’re sitting there, contemplating the start of a new project. You have (perhaps) a potential team of programmers, project managers, office cleaners, specification gurus, architects, testers, telephone sanitizers, configuration management specialists etc. How are you going to coordinate them? How are they going to coordinate themselves? Even imagining the strictly personnel management side has been taken care of (or not) according to the whims and working of your company, the technical management is more difficult. You’ll need an agreed way of working, of agreeing in advance what we’re going to do, and of cementing technical contracts between developers – in other words, you need a methodology. There are many Audi-driving ‘consultants’ who will gather around to help you help them meet their sales quotas. But how do you make the right decision? Almost always, this decision gets ignored. Perhaps one particular methodology is allpervasive in the developers’ world. Perhaps they’re all fired up and enthusiastic about the latest CV-enhancing opportunity a new approach will give them. Perhaps nobody’s ever given the time to thinking about that at all, and therefore the approach has defaulted to the last common denominator [8]. And perhaps, just perhaps, whichever approach is used is in fact the best one for the job. But don’t bet on it! In this paper we’re going to look at some various methodologies in common use in the current decade. This paper won’t teach you how to use them, or even very much about what they do, but rather it will highlight features and strengths and weaknesses of each for different kinds of projects.